Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Dedup duplicate crates with differing origins in CrateGraph construction #15754

Merged
merged 7 commits into from
Nov 23, 2023

Conversation

alibektas
Copy link
Member

@alibektas alibektas commented Oct 13, 2023

Partially fixes #15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different CrateOrigins the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in #15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 13, 2023
@alibektas alibektas changed the title Relaxation for crate graph mergin fix : relax dedup rules for crate graphs Oct 13, 2023
@alibektas alibektas changed the title fix : relax dedup rules for crate graphs fix: relax dedup rules for crate graphs Oct 13, 2023
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/cfg/src/lib.rs Outdated Show resolved Hide resolved
crates/rust-analyzer/tests/slow-tests/main.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
@alibektas alibektas force-pushed the 15656/linked_projects_are_local_too branch 2 times, most recently from 91225bb to bf53935 Compare October 15, 2023 16:25
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
@alibektas
Copy link
Member Author

Forgot to move dev deps from lib crate to the local, so please wait for the next commit before reviewing

@alibektas alibektas force-pushed the 15656/linked_projects_are_local_too branch from fe7f479 to c3f90bb Compare November 11, 2023 12:49
@alibektas
Copy link
Member Author

This is ready to be reviewed a third time

crates/cfg/src/lib.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
crates/base-db/src/input.rs Outdated Show resolved Hide resolved
Partially fixes rust-lang#15656 . When a crate graph is extended which is the case when new workspaces are added to the project
the rules for deduplication were too strict. One problem that arises from this is that in certain conditions
when we see the same crate having different `CrateOrigin`s the first form would be maintained. This approach however
results in some unwanted results such as making renaming forbidden as this has been recently only made available for
local crates. The given example in rust-lang#15656 can still not be resolved with this PR as that involves taking inconsistencies
between dependencies into consideration. This will be addressed in a future PR.
Make data reflect a case where dev deps are existent.
base-db::CrateGraph::extend now adds dev dependencies for a crate
in case of its upgrading from a CrateOrigin::Lib kind of a crate to a
CrateOrigin::Local one.
@alibektas alibektas force-pushed the 15656/linked_projects_are_local_too branch from ef9bc3e to be91d95 Compare November 23, 2023 01:46
@Veykril
Copy link
Member

Veykril commented Nov 23, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Nov 23, 2023

📌 Commit be91d95 has been approved by Veykril

It is now in the queue for this repository.

@Veykril Veykril changed the title fix: relax dedup rules for crate graphs fix: Dedup duplicate crates with differing origins in CrateGraph construction Nov 23, 2023
@bors
Copy link
Contributor

bors commented Nov 23, 2023

⌛ Testing commit be91d95 with merge 49b8a8e...

bors added a commit that referenced this pull request Nov 23, 2023
… r=Veykril

fix: Dedup duplicate crates with differing origins in CrateGraph construction

Partially fixes #15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in #15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
@bors
Copy link
Contributor

bors commented Nov 23, 2023

💔 Test failed - checks-actions

@alibektas alibektas force-pushed the 15656/linked_projects_are_local_too branch from 7dabf27 to 32f382e Compare November 23, 2023 10:23
@lnicola
Copy link
Member

lnicola commented Nov 23, 2023

@bors retry

@Veykril
Copy link
Member

Veykril commented Nov 23, 2023

That last commit contains nothing?

@Veykril
Copy link
Member

Veykril commented Nov 23, 2023

(also retry only works when the PR history has not been changed since the last r+)

@lnicola
Copy link
Member

lnicola commented Nov 23, 2023

Yeah, last commit is empty, but there was a force-push that did change some paths: https://github.com/rust-lang/rust-analyzer/compare/7dabf2718ef3724d12d9999c120d21df343253c6..32f382e4e8ea841da991ff3c3faade3e4d5052c5.

@alibektas alibektas force-pushed the 15656/linked_projects_are_local_too branch from 32f382e to 736994f Compare November 23, 2023 10:54
@Veykril
Copy link
Member

Veykril commented Nov 23, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Nov 23, 2023

📌 Commit 736994f has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Nov 23, 2023

⌛ Testing commit 736994f with merge 98fbe82...

bors added a commit that referenced this pull request Nov 23, 2023
… r=Veykril

fix: Dedup duplicate crates with differing origins in CrateGraph construction

Partially fixes #15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in #15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
@bors
Copy link
Contributor

bors commented Nov 23, 2023

💔 Test failed - checks-actions

@lnicola
Copy link
Member

lnicola commented Nov 23, 2023

@bors r=Veykril

@bors
Copy link
Contributor

bors commented Nov 23, 2023

📌 Commit ba1b080 has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Nov 23, 2023

⌛ Testing commit ba1b080 with merge cccc7ca...

@bors
Copy link
Contributor

bors commented Nov 23, 2023

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing cccc7ca to master...

@bors bors merged commit cccc7ca into rust-lang:master Nov 23, 2023
9 checks passed
Normal,
Dev,
Build,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't take this too seriously, as I have retreated to my Zig ivory tower in Lisbon some years ago and am mostly out of touch with the current goings of rust-analyzer, but I would say this is a significant architectural bug.

By design, this layer of rust-analyzer knows nothing about cargo specific concepts. dev-vs-build-vs normal is 100% Cargo concept. rustc knows nothing about these words. As such, any special handling of these concepts should happen in workspace.rs, not here.

The motivation for this design is two-fold:

  • practically, Cargo is a build system, there might be others. In the core analysis parts, we shouldn't be prioritizing Cargo over other (current and future) build systems
  • theoretically, it is important that the internal objects in rust-analyzer's semantic model reflect the physical reality of rustc. In that physical reality, cargo packages do not exists (and -dev as a concept applies to a package), there are only units of compilation.

cc @Veykril

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't take this too seriously,

Not at all, you are completely right, this seems incorrect. This was a mistake on my part (I proposed this change somewhere I believe, might've been in DMs).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to check for equality we needed to filter out dev dependencies and thus we ended up with the current state of things. The alternatives were

  1. To filter them in project_model : I am looking into this since @matklad 's first comment here, I do not think it is going to be easy.
  2. Adding project-model as a dependency of base-db which is ofc super wrong to do. ( As a matter of fact we already do have a DependencyKind under project-model named DepKind )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But let me say that I also agree with matklad's concerns so I will look for a way to rectify this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Since 0.4.1658] Cannot rename a non-local definition.
6 participants